[小ネタ]Security Hubの重要度の基準を調べてみた

#AWS

#AWS Security Hub

和田響

2024.11.05

はじめに

こんにちは。AWS事業本部コンサルティング部に所属している和田響です。

Security HubはAWS環境内のセキュリティリスクを重要度別に評価してくれるサービスで、非常に便利なことは言うまでもありません。
Security Hubを見ない日はない私ですが、ふと最近「Security Hubの重要度ってどうやって決まってるんだろう？」と疑問が浮かびました。

公式ドキュメントに書いてありました！

この記事では公式ドキュメントをもとに、Security Hubの重要度についてまとめてみます。

重要度の種類

Security Hubの重要度は以下の5種類が存在します。

重大（Critical）
高（High）
中（Medium）
低（Low）
情報（Informational）

重要度の基準

重要度の基準は簡単に表すと「悪用の難易度 x 侵害可能性」で決まっているようです。

Untitled - 2024-11-02T005641.245.png
参照：https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/controls-findings-create-update.html#control-findings-severity

コントロールの重要度は、以下の基準の評価に基づいて決定されます:

・脅威アクターがコントロールに関連する設定の弱点を利用する際の難易度
　この難易度は、弱点を利用して脅威シナリオを実行するために必要な洗練度または複雑さの度合いによって決まります。

・弱点がの侵害につながる可能性はどの程度ありますか AWS アカウントまたはリソース？
　の侵害 AWS アカウントまたはリソースとは、お客様のデータの機密性、完全性、または可用性を意味します。 AWS イン>フラストラクチャが何らかの形で破損している。
　侵害の可能性は、脅威シナリオがの中断または違反につながる可能性を示します。 AWS サービスまたはリソース。

容易に悪用が可能で侵害の可能性が高いリスクほど、高い重要度で評価されるようです。

以下、重要度が "重大（Critical）" のFSBPのコントロールですが、 「リソースをパブリックに公開することは非常にリスクが高い」 というAWSからのメッセージを感じますね。

[ SSM.4 ] SSMドキュメントはパブリック公開してはいけません

[ S3.1９ ] S3 アクセスポイントではブロックパブリックアクセス設定を有効にする必要があります

[ S3.3 ] S3 汎用バケットはパブリック書き込みアクセスを禁止する必要があります

[ S3.2 ] S3 汎用バケットはパブリック読み取りアクセスを禁止する必要があります

[ Redshift.1 ] Amazon Redshiftクラスタはパブリックアクセスを禁止すべき

[ RDS.2 ] RDS DB インスタンスはパブリックアクセスを禁止する必要があります。PubliclyAccessible 設定によって決まります。

[ RDS.1 ] RDS スナップショットはプライベートにする必要があります

[ Opensearch.2 ] OpenSearchドメインはパブリック公開してはいけません

[ Neptune.3 ] Neptune DBクラスタースナップショットはパブリックにしないでください

[ Lambda.1 ] Lambda 関数は、他のアカウントによるパブリックアクセスを禁止する必要があります

[ KMS.3 ] AWS KMSのキーは意図せずに削除してはいけない

[ IAM.6 ] ハードウェア MFA はルートユーザーに対して有効にする必要があります

[ IAM.4 ] IAM ルートユーザーアクセスキーは存在してはなりません

[ ES.2 ] Amazon Elasticsearch Serviceのドメインはパブリック公開してはいけません

[ EMR.2 ] Amazon EMR ブロックのパブリックアクセス設定を有効にする必要があります

[ EC2.19 ] セキュリティグループは、リスクの高いポートへの無制限のアクセスを許可してはならない

[ EC2.1 ] Amazon EBS スナップショットはパブリックに復元可能であってはなりません。

[ DocumentDB.3 ] Amazon DocumentDB 手動クラスタースナップショットはパブリックにできません

[ DMS.1 ] Database Migration Service のレプリケーションインスタンスはパブリックであってはなりません

[ CodeBuild.2 ] CodeBuild プロジェクトの環境変数には、クリアテキストの認証情報を含めないでください

[ CodeBuild.1 ] CodeBuild Bitbucket ソースリポジトリ URL には機密性の高い認証情報を含めないでください

[ CloudFront.1 ] CloudFrontのディストリビューションでは、デフォルトのルートオブジェクトが設定されている必要があります

重要度に応じてどう対処すべきか

これもドキュメントに書いてありました！
以下、内容を簡単にまとめます。

重要度	必要な対応
重大（Critical）	直ちに修復する必要がある
高（High）	短期的な優先事項として対処する必要がある
中（Medium）	中期的な優先事項として対処する必要がある
低（Low）	すぐにアクションを実行する必要はないが、他の問題と相関関係がある場合は対処する
情報（Informational）	対応不要

重大 - この問題は、さらに悪化しないように直ちに修復する必要があります。
例えば、公開された S3 バケットは重大な重要度の結果と考えられます。非常に多くの脅威アクターによって、公開された S3 バケットがスキャンされるため、公開された S3 バケット内のデータは、他者によって発見およびアクセスされる可能性があります。
一般に、パブリックにアクセス可能なリソースは、セキュリティ上の重大な問題と見なされます。重大な結果への対応は、緊急性が最も高くなります。また、リソースの重大度も考慮する必要があります。

高 - この問題は短期的な優先事項として対処する必要があります。
例えば、デフォルトのVPCセキュリティグループがインバウンドトラフィックとアウトバウンドトラフィックに対して開いている場合、重要度が高いと見なされます。脅威アクターがこの方法VPCを使用してを侵害することは、ある程度簡単です。また、脅威アクターは、リソースがに入ると、リソースを中断または抽出できる可能性もありますVPC。
Security Hub では、重要度の高い結果を短期的な優先事項として扱うことを推奨しています。すぐに修復手順を実行する必要があります。また、リソースの重大度も考慮する必要があります。

中 - この問題は、中期的な優先事項として対処する必要があります。
例えば、転送中のデータの暗号化が欠如している場合、重要度が中程度の結果と考えられます。この弱点を利用するには、高度な man-in-the-middle 攻撃が必要です。つまり、やや難しい攻撃手法です。脅威シナリオが成功すると、一部のデータが侵害される可能性があります。
Security Hub では、できるだけ早く、関連するリソースを調査することを推奨しています。また、リソースの重大度も考慮する必要があります。

低 - この問題には、独自のアクションは必要ありません。
例えば、フォレンジック情報の収集に失敗した場合、重要度が低いと考えられます。この管理は将来の侵害を防ぐのに役立ちますが、フォレンジックが実行されない限り、侵害に直接つながりません。
重要度の低い結果については、すぐにアクションを実行する必要はありませんが、他の問題と相関関係がある場合は、コンテキストを入手できます。

情報 - 設定の弱点は見つかりませんでした。
つまり、ステータスは PASSED、WARNING、または NOT AVAILABLE です。
推奨されるアクションはありません。通知目的の結果は、顧客が準拠状態であることを実証するのに役立ちます。